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Introduction 


Presently, the largest utilization of 
automatic test equipment (ATE) is for 
printed circuit board troubleshooting, 
but after the boards are assembled into 
a mainframe the final test process is a 
time-consuming effort. The use of ATE 
is now expanding from the trouble 
shooting of printed circuit boards to the 
testing of completed units or systems. 
Using automatic test systems to do 
receiver specification testing is a logical 
progression of this expansion of ATE 
use. Specification testing lends itself 
ideally to automation because of its 
highly repetitious nature. The nation- 
wide attempts to increase productivity 
are pushing the use of automation 
throughout industry. More specifically, 
the increased complexity of electronic 
assemblies combined with the shortage 
of skilled technical manpower is in- 
creasing the need for automatic test 
systems at all levels of testing. The 
development of IEEE standard 488, a 
standardized instrumentation bus, and 
the instrument manufacturers response 
to it, has led to the manufacture of 
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hundreds of instruments for use on the 
bus. These events have helped to meet 
the need for automation by allowing 
automatic test systems to be imple 
mented in a cost effective manner. 


The measurement of any given receiver 
specification is basically a fivestep 
process: 1) Connection of the appro- 
priate instrumentation; 2) Set-up of the 
stimulus instruments; 3) Set-up of the 
receiver under test; 4) Set-up and read- 
ing of the measurement instruments; 
and, 5) Interpretation of the data. 


During manual testing, each of these 
five steps is performed by a technician 
with the arrangement shown in Figure 
1. The technician sets-up and reads the 
instrumentation and the receiver, then 
either directly records the resultant 
reading or uses that reading to calculate 
the desired data. The user’s problem is 
that although testing of this type is 
repetitious, it is still necessary to utilize 
skilled personnel to obtain good test 
results manually. 


Automation of the manual testing pro- 
cess does not alter the five basic test 


MEASUREMENT 
INSTRUMENT 
MEASUREMENT 
INSTRUMENT 






Figure 1. Basic manual test set-up. 














steps. As shown in Figure 2, by allow- 
ing the system controller access to the 
instrumentation and receiver, it can 
now perform these steps automatically. 
Now, the connection, set-up and read- 
ing of the instrumentation, as well as 
the data interpretation, are all done by 
the system controller. 


Benefits 


The first and most obvious benefit of 
automatic testing is increased speed 
and throughput. Use of automatic test 
systems for receiver specification test- 
ing can result in an approximate 90- 
95% cut in test time. One important 
benefit derived from this increase in 
speed is a reduction in labor costs, 
which mainly occur for two reasons: 

1) With increased throughput, test per- 
sonnel needs decline, along with the 
amount of necessary test equipment. 

2) Less skilled personnel can be utilized 
for repetitious testing, since the testing 
process has been reduced to machine 
operation. These benefits greatly ease 
skilled technical manpower require- 
ments and free skilled technicians for 
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more useful and challenging assign- 
ments, an important consideration 
with the current shortage of available 
technical manpower. 


Another benefit of automated testing is 
that of accuracy and repeatability in 
the test process. The system controller 
has full power over the measurements; 
therefore, no human error is introduced 
into the readings. The system con- 
troller, being a machine, feels no pres- 
sure to increase output by allowing 
marginal units to pass through the 
system. In addition, the software com- 
pensates for predictable, repeatable 
system errors, such as cabling losses 
and other factors inherent in the 
system. There are no variations in how 
the tests are run from unit to unit, so 
there is a constant repeatability factor 
which provides much greater confi- 
dence in the test results. 


Past Problems With Automation 


In the past there have been several 
problems associated with automating 
the receiver test process, the most expen- 
sive being the very large software effort. 
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Figure 2. Basic automatic test set-up. 


Programming is time-consuming, labor- 
intensive and, therefore, very costly. 
The real problem here is that every user 
is producing the same type of general 
receiver tests to accommodate their test 
hardware and a particular receiver. 
Often, the same user will duplicate 
their own efforts to adapt new software 
to another receiver, even if the new 
receiver is to be tested on the same test 
system. The long programming, and 
often reprogramming effort is not only 
costly, but because of the time involved, 
also leaves an interim period where 
manual testing of the receiver is 
necessary while waiting for the test soft- 
ware to become available and usable. 
An additional problem has been that 
programming on the system would 
preclude the possibility of testing on the 
system. Therefore, the programs that 
had been completed could not be used 
as long as the system was being utilized 
to accomplish software development. 


The Compute-intensive Concept 


Watkins-Johnson Company has devel- 
oped a line of Compute Intensive Test 
Equipment (CITE). The compute inten- 
sive concept solves the past problems 
associated with automated receiver test- 
ing. Since software is the user’s largest 
expense in bringing an automatic 
system on line, the major CITE design 
criteria was to minimize the user’s 
software development. By using a 
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software-intensive system organiza- 
tion, a general, highly flexible system is 
obtained. Menu driver software is used 
to guide the user through the entire 
programming and operation phases of 
receiver testing. The user, therefore, 
does not do actual receiver test pro- 
gramming, but only fills in the blanks, 
via the menus, to give the necessary 
input to the already existing software. 
The system software then inserts the 
user inputs into the resident receiver 
test software, which assembles the 
necessary test programs automatically. 


Use of the powerful UNIXT* operating 
system helps to solve other problems 
previously associated with automatic 
receiver testing. Being a multi-user 
operating system, UNIX™ allows the 
system hardware to be configured as 
shown in Figure 3. With a single ter- 
minal used to control the test execution, 
other terminals can be connected to the 
CPU for use as programming stations. 
This allows several programmers to 
proceed with software development, or 
other tasks, simultaneously with test 
execution. 


System Development 


Development of a receiver test system 
is an integrated process of both hard- 
ware and software design. Generally, 
the hardware must at least be defined 
before the software development can be 
started. Once that hardware definition 
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Figure 3. Multi-user ATE configuration. 


*Registered trade mark of Bell Systems Laboratories. 














takes place, hardware and software 
development can both proceed hand-in- 
hand. Integration of hardware and soft- 
ware is continual through the entire 
System engineering process. 


Hardware Development 


The heart of the receiver test system 
hardware is the receiver interface. This 
unit is responsible for all switching and 
interconnection between the receiver 
under test and the test system. The unit 
must be designed keeping in mind all 
the necessary connection possibilities 
between the receiver and the system 
instrumentation. Instrumentation 
should be chosen, whenever possible, 
with an IEEE 488 interface to simplify 
system integration. The test hardware 
and instrumentation then has only one 
interface point, the IEEE 488 bus, with 
the main system controller complex. 
This controller complex will generally 
consist of a CPU, mass storage (such as 
a floppy or hard disc drive), a terminal 
and asystem printer. Figure 4 is a basic 
block diagram of the test system hard- 






IEEE 488 BUS 






SYSTEM 
CONTROLLER 
HARD CRT 
DISC TERMINAL 
PRINTER 


SIGNAL 
GENERATOR 
SIGNAL 
GENERATOR 
LOW 
FREQUENCY 
. GENERATOR P 


ware. The utilization of the IEEE 488 
bus increases the modularity of the 
system and facilitates any future 
expansion of the system which may 
become necessary. 


Software Development 


The first step in the development of test 
system software is the generation of 
driver subroutines for each instrument 
in the test system. This facilitates ease 
of instrument handling by the actual 
test programs and eliminates repeti- 
tious use of instrument programming 
statements. The test programs can then 
access the instruments simply by pass- 
ing parameters back and forth, to or 
from, the subroutines. The use of intel- 
ligent instrumentation in the system 
can function as a form of distributed 
processing. This technique allows some 
of the controller workload to be off- 
loaded to the instrumentation. For 
example, an intelligent digital volt- 
meter with peak storage capability can 
take many readings, always keeping in 
memory the highest and lowest ones. 
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Figure 4. General automatic receiver test system. 


These peak readings are then passed 
back to the controller. This relieves the 
controller of the task of reading every 
measurement and sorting out the high- 
est and lowest readings. 


After the generation of driver sub- 
routines for the instrumentation, the 
actual receiver test programs are then 
generated. Since this effort becomes the 
most costly aspect of system genera- 
tion, this is where the CITE philosophy 
attempts to simplify the user’s effort. 
General purpose menu software is 
generated which, when operated, 
prompts the user to input the necessary 
information (see Figure 5). This then 
allows the user to call up the menus for 
the desired tests and to input the 
necessary parameters. The internal 
software then generates the necessary 
test programs automatically, eliminat- 
ing a time consuming programming 
effort for the system user. 





The compute-intensive concept is to 
fully utilize the computing power of the 
CPU. Whenever possible, capabilities 
are moved from hardware to software, 
particularly when this move can 
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eliminate certain pieces of hardware 
thereby minimizing the total system 
cost. As an example of this philosophy, 
the following discussion of noise figure 
will show how the compute intensive 
concept can eliminate the need for a 
noise figure meter and provide more 
accurate noise figure readings utilizing 
an RF voltmeter which already exists 
in the system. 


Noise figure is a measure of the amount 
of signal-to-noise ratio (S/N) degrada- 
tion through a system. Therefore, noise 
figure (F) is: 


aclen iE IS ot: 


F= 
S/N, S. N; 





Where: S; = Input signal power 
S, = Output signal power 
N; = Input noise power 
N, = Output noise power 


Since represents the gain (G) of the 


system, this then becomes : 
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The output noise (N,) has two compo- 
nents: First, the input noise (N;) times 
the gain of the system (N;G) and 
secondly, any extra noise, (N,,), which is 
added by the system. The noise figure 
equation then becomes: 


N,(G)+N, Ny, 
ee 
N;,(G) N,(G) 


It is this extra noise (N,) component 
which determines the signal-to-noise 
degradation and, therefore, the noise 
figure. In a theoretically noiseless 
system, N, would be 0, which results in 
a noise figure of 1. Itis more commonly 











acceptable to express noise figure in 
dB, which is simply: 
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N,(G) 





Fdb = 10 log F = 10 log (1 + ) 


Our theoretically noiseless system now 
has a noise figure in dB of 10 log 1 or 
O dB. 


To gain further insight into the prob- 
lem of directly measuring noise figure, 
recall the previous equation: 


No 
N,(G) 





The input noise (N;) is actually the 
thermal noise from the input termina- 
tion, which is equal to k T, B, where: 


k = Boltzman’s constant 
(1.38 x 10-23) 

T, = Input Termination 
Temperature (Room 
Temperature, 290°k) 

B = Bandwidth over which the 
noise power is measured 


The equation above then becomes: 
No 
kT.BG 





RECEIVER 
ADDED NOISE 
(F-1) kToBG 


INPUT NOISE 
x GAIN 
(kKT)>BG) 





(a) 


The practical difficulties in directly 
measuring the input noise (kT,B) 
accurately, forces the use of an alter- 
native method rather than a direct 
measurement technique. This alter- 
native method is illustrated in Figure 6. 
In addition to measuring the output 
noise, N,, as shown in Figure 6a, 
another measurement is taken of the 
output noise, No, which includes extra 
input noise injected by a noise source. 
These two measurements alone, N, 
and No, are all that is necessary to 
calculate the system noise figure. 


To understand this concept, it is first 
necessary to define the three noise 
components: input noise, receiver added 
noise and the extra noise from the noise 
source. The input noise has already 
been defined as kT, B. This factor times 
the system gain (kT,BG) identifies the 
input noise component at the output of 
the system. In like manner, the extra 
noise component from the noise source 
can be defined as k(T> - T,)BG, where 
T> is the equivalent noise temperature 
of the noise source when turned on. 


The remaining noise component, that 
noise added by the receiver, can be 
derived as follows: The extra noise(N,) 
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Figure 6. Noise figure measurement. 


added by the receiver is equivalent to the noise output (N,) minus the input noise, 
or, 





N, =N,.- kT,BG (1) 
Solving the previous noise figure equation for output noise yields the following: 
kT,BG 
N, = kT,BGF (2) 


Substituting equation (2) into equation (1) will yield the formula for the noise 
added by the receiver (N,,). 


N, = kT,BGF - kT,BG 
= (F-1) kT,BG 


It is now possible to define the ratio No/N; as follows: 


N2_ Input Noise + Receiver Added Noise + Noise Source Noise 
N, Input Noise + Receiver Added Noise 


No _ kT,BG + (F-1)kT,BG + k(T2 - T,)BG 








Ni kT,BG + (F-1)kT,BG 
Simplifying: 
No _ FI, + (Tp - Ty) 
N, FT, 
, ee ey ty) 
FT, 
Solving for F: 
(T'y - Ty) 
1 
(fea 
No 
Ni 
Converting to dB: 
( ) 
FdB = 10 log -10log {—- 
0) 1 
(T - Ah) A : 3 . 
The term 10 log is a measure of the noise power from the noise source. This 
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is defined as the excess noise ratio (ENR) specified by the manufacturer of the 
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noise source and will typically vary a 
few tenths of a dB over the frequency 
range of use. For most noise diodes 
available, the ENR will be approxi- 
mately 15.2 dB. The final noise figure 
equation then becomes: 


No 
FdB = ENR - 10 log | —- 1 
N, 


The only two unknowns, No and N;, 
can be read directly at the output and 
fed into this equation. 


This concept more fully utilizes the 
computing power of the CPU to 
eliminate the need for a special piece of 
hardware. This philosophy, when car- 
ried throughout each individual test, 
will produce an efficient system of 
minimal hardware with more fully 
utilized software capabilities. 


Receiver Diagnostics 


After all the receiver’s specifications 
are gathered and analyzed, the most 
obvious question then becomes, “Can 
the troubleshooting process be auto- 
mated if the specifications are out of 
tolerance?” There are two ways to 
approach the automated diagnostics 
process. The most obvious is to 
mechanically interface to the internal 
circuitry of the receiver and trace the 
signal through the receiver to be certain 
of proper signal processing. There are 
numerous problems associated with 
this method. First, depending on the 
mechanical design of the receiver, it 
may require extensive engineering to 
solve this interface problem. Second, 
interfacing to the required number of 
test points may load the receiver too 
heavily and cause its operation to cease. 
If these problems can be overcome, it 
may be cost effective to pursue this 
option in a production environment for 
a single receiver product, but in a depot 


situation, where many different 
recelvers must be maintained, the cost 
of developing many interfaces of this 
kind cannot be justified. 


In reality, even in a production environ- 
ment, it generally is not cost effective to 
use this method of automated diagnos- 
tic testing. The technician working on 
a particular receiver in production 
becomes intimately familiar with that 
product. He can then look at the result- 
ing specifications and identify the 
problem area from experience. There- 
fore, diagnostic testing to a module 
level, generally is never cost effective in 
a production environment. In contrast, 
the depot technician works on many 
different receivers and never really 
attains detailed familiarity with all of 
them. His need for diagnostic testing, 
therefore, is much greater than that of 
the production technician’s. The solu- 
tion to this problem is once again the 
computeintensive concept. Software 
analysis of the resultant specifications 
can be used to identify the failing 
module. In actuality, this automates 
the production technician’s thought 
processes in arriving at the module 
with the highest probability of failure. 
This process, while not true diagnostic 
testing, provides a solution to the 
problem which is usable and economi- 
cally feasible. 


Management Enhancements 


Due to the increased power of smaller 
computers available for use in these 
test systems, it is possible to employ 
data management techniques from the 
data processing industry within the 
testing environment. As testing takes 
place, individual test data can be stored 
within the printer controller. At the 
completion of testing for any particular 
receiver, the printer controller can first 
scan all of the data collected for that 
receiver. If all data is not within 


specification, a failure list can be 
printed for the receiver. If the data is 
found to be acceptable, the printer 
controller can begin printing a customer- 
deliverable data sheet which can be 
formatted as desired. The next receiver 
could then be started as the first 
receiver's data sheet is printing. The 
data for receiver number two could be 
loaded under interrupt control. This 
method of distributed processing is very 
useful for increasing overall through- 
put. As test data is collected by the 
system, it is stored and kept available 
for management use. This process then 
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forms a complete product data base. 
Applications software can then be used 
to analyze this data base to obtain 
product trends or other useful manage 
ment information as necessary. It 
would be possible to retrieve a particular 
piece of data from any particular 
receiver, such as noise figure for serial 
number 87, for example, or to analyze 
data from a group of receivers, such as 
the average noise figure of serial num- 
bers 20-100. This becomes a valuable 
tool for product analysis and enables 
the user to see any trends which may 
develop during the life of a product. 
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